В догонку к найденным и, вроде бы, поборенным уязвимостям Meltdown и Spectre, в процессорах Intel нашли еще одну потенциальную дыру - L1 Terminal Fault Vulnerability, которая затрагивает современные процессоры (2009-2018 годов выпуска) и гипервизор VMware ESXi (а также и все остальные гипервизоры).

Для начала надо сказать, что на днях стали доступны вот такие патчи для платформы виртуализации VMware vSphere, которые настоятельно рекомендуется установить:

VMware vCenter:

• vCenter Server 6.7 – VC 6.7.0d build 9451876
• vCenter Server 6.5 – VC 6.5 Update 2c – build 9451637
• vCenter Server 6.0 – VC 6.0 Update 3h – build 9451619
• vCenter Server 5.5 – VC 5.5 Update 3j – build 9313450

VMware ESXi:

• ESXi 6.7 – ESXi670-201808401-BG
• ESXi 6.5 – ESXi650-201808401-BG
• ESXi 6.0 – ESXi600-201808401-BG
• ESXi 5.5 – ESXi550-201808401-BG

Суть уязвимости, описанной в CVE-2018-3646 заключается в том, что виртуальная машина, исполняемая на конкретном ядре, может получить доступ к данным других машин, использующих это ядро, или самого гипервизора через L1 Data Cache, который совместно используется машинами, выполняющими команды на данном ядре.

Для такой уязвимости возможны 2 типа векторов атаки:

• Sequential-context - вредоносная машина получает доступ к данным другой ВМ, которая исполнялась на этом ядре ранее и получала доступ к кэшу L1.
• Concurrent-context - вредоносная машина прямо сейчас получает доступ к данным ВМ или гипервизора, которые исполняются планировщиком на этом ядре.

Решение вопроса уровня Sequential-context заключается просто в накатывании патчей, которые не должны приводить к падению производительности (как это было с Meltdown и Spectre). А вот для избавления от риска применения вектора атаки Concurrent-context нужно включить фичу, которая называется ESXi Side-Channel-Aware Scheduler. И вот в этом случае влияние на производительность может уже быть существенным, поэтому нужно либо принять риск Concurrent-context, либо следить за производительностью систем.

Таким образом, процесс обновления инфраструктуры VMware vSphere должен выглядеть так:

• Обновляете сначала серверы vCenter, потом хосты ESXi.
• Смотрите, есть ли на хостах запас по CPU на случай возникновения проблем с производительностью.
• Если запас есть - включаете функцию ESXi Side-Channel-Aware Scheduler и наблюдаете за производительностью систем по CPU.

Детальные инструкции по включению ESXi Side-Channel-Aware Scheduler вы найдете здесь. Действовать нужно по следующей схеме:

Ну и в заключение, вот список процессоров, которые подвержены атакам типа L1 Terminal Fault:

На днях компания VMware выпустила финальную версию своего руководства по обеспечению безопасности виртуальной инфраструктуры vSphere 6.7 Update 1 Security Configuration Guide. Напомним, что ранее мы писали о документе vSphere 6.5 Update 1 SCG, который описывал основные аспекты обеспечения безопасности прошлой версии платформы (оказывается, был и гайд по vSphere 6.7 - он публично не анонсировался, но теперь находится в статусе Deprecated).

Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.

В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:

• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
• Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.

Сейчас распределение по этим настройкам выглядит так (50 настроек в vSphere 6.7 U1 против 68 опций в версии vSphere 6.5 U1):

Давайте посмотрим на отличие vSphere 6.7 U1 SCG от прошлых версий руководства:

• Появились настройки категории deprecated - они описывают параметры ESXi или vCenter, которые больше нет необходимости изменять, так как они потеряли актуальность. Все настройки этой категории приведены в отдельном документе, который настоятельно рекомендуется изучить. Если вы их использовали - то лучше перестать это делать, так как это только добавляет дополнительной работы по их обслуживанию.
• Больше нет категории "Risk Profiles". Причина в том, что только настройка "ESXi.enable-strict-lockdown-mode" подпадает под Risk Profile 1, а остальные находятся во 2-й или 3-й категории, поэтому было решено отказаться от этой таксономии. Вместо этого было добавлено больше содержимого в колонку Vulnerability Discussion, где обсуждаются конкретные факторы риска.
• Настройка vNetwork.enable-bpdu-filter переместилась из категории Hardening в Site Specific, так как при нормальных условиях функционирования сети ее менять не требуется (а она также затрагивает конфигурацию аппаратных коммутаторов и гостевой ОС). Да, она защищает от Spanning Tree Loops, но в нормально настроенной сетевой конфигурации менять ее не следует.

В гифке ниже можно посмотреть прогресс Security Configuration Guide с версии vSphere 6.5:

Скачать VMware vSphere 6.7 Update 1 Security Configuration Guide можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная полезность - утилита True SSO Diagnostic Utility. С ее помощью можно проводить диагностику сертификатов Horizon View Enrollment Server (ES), настроек Active Directory PKI и свойств служб сертификации Enterprise Certificate Authorities (CA).

Horizon View True SSO использует серверы Microsoft Enterprise Certificate Servers для выпуска сертификатов, которые используются при логине пользователя в гостевую ОС виртуального ПК. Horizon View Enrollment Server ответственен за то, чтобы послать запрос на серверы сертификации, а также за мониторинг конфигурационных настроек PKI в инфраструктуре Active Directory.

Утилита True SSO Diagnostic Utility поможет вам найти причину проблем с выпуском и использованием сертификатов:

Для того, чтобы сервер ES мог выпускать сертификаты для пользователей, нужно чтобы было соблюдено несколько требований:

• ES должен быть установлен в системе, которая является членом домена, где есть пользователь, либо из домена с двусторонним трастом к этому домену. Также он не может быть установлен на контроллер домена или Connection Server, но может быть установлен совместно со службой CA.
• Должна быть сделана настройка шаблона сертификата со службой Smartcard Logon, а ES должно быть выдано разрешение Enroll на этот шаблон.
• Для нужного шаблона должна быть настроена служба Enterprise CA для выпуска сертификатов.
• Сертфикат Enrollment Certificate, который генерируется Enterprise CA из леса, где находятся пользователи, должен быть установлен в хранилище сертификатов на ES.
• Сервер (или View Pod) Horizon View Connection должен быть слинкован в ES.

Утилиту True SSO Diagnostic Utility нужно скопировать на Horizon 7 Enrollment Server и запускать ее там. Руководство по ее использованию можно скачать тут, а саму утилиту здесь.

На прошлой неделе компания Veeam в Праге собирала участников сообщества Veeam Vanguards 2018, где мы пили чешское и катались по Влтаве. Но самым интересным было не это, а рассказы о перспективах компании, ее новых продуктах и технологиях, о которых мы расскажем в ближайшем будущем.

Один из самых ожидаемых релизов - это Veeam Backup and Replication 9.5 Update 4, который, скорее всего, будет официально поддерживать резервное копирование виртуальных машин на недавно вышедшей новой версии платформы VMware vSphere 6.7 Update 1 (хотя и на данный момент фактически он на ней прекрасно работает, но нужно кое-что сделать).

В новой версии VBR будет много всего полезного, но давайте остановимся на двух возможностях. Первая - это функция Staged Restore, которая позволяет проводить манипуляции с данными внутри бэкапов с помощью скриптов перед их реальным восстановлением в производственную среду.

Главное назначение этой возможности - соблюдения комплаенса GDPR (если вы работаете с данными европейцев), который закрепляет, в частности, за бывшим работником организации право на удаление персональной информации о нем, которая хранится, как минимум, в Active Directory. Поэтому с помощью сценариев можно удалить аккаунт бывшего пользователя из AD и, например, его почтовый ящик из Exchange, чтобы не нарваться на нарушение и штраф.

Схема выглядит так - администратор восстанавливает резервную копию в полностью изолированное окружение, с помощью сценария PowerShell удаляет из машины требуемые данные, после чего она переходит в производственную среду:

В принципе, вы можете создать список действующих сотрудников в текстовом документе и удалять из бэкапа тех, кто ему не соответствует. Но для этого надо быть знакомым с PowerShell. Ну а примеры подобных сценариев вы скоро найдете в репозитории Veeam на GitHub (VeeamHub).

Вторая интересная фича Update 4 - это возможность проверки антивирусом резервной копии перед восстановлением (как раз на стадии Staged Restore), чтобы она не заразила производственную среду:

Причем поддерживаются не только самые распространенные антивирусы, но и с помощью сценариев вы сможете интегрировать любой антивирус, который поддерживает запуск из командной строки. В этом случае виртуальная машина и ее данные как бы помещаются на карантин (Antivirus Quarantine) и далее, пролечившись, они могут быть восстановлены в продакшен.

Зачем это нужно, если у вас уже есть антивирус внутри ВМ? Очень просто - есть атаки, называемые Zero-day, то есть, например, ваши данные были заражены вирусом, о котором еще не знает ваш антивирус. В этом случае в бэкап этот вирус попадет, ну а при восстановлении он заразит вашу виртуальную машину, вызвав, например, полное блокирование ее работы.

Процесс Secure Restore позволяет защититься от этого вида уязвимостей:

Более подробно о новых возможностях Veeam Backup and Replication 9.5 Update 4 мы расскажем в ближайшем будущем - когда он выйдет.

Это гостевой пост нашего партнера - компании ИТ-ГРАД, предоставляющей услугу уренды виртуальных машин из облака.

В Евросоюзе обработку персональных данных регулирует небезызвестная директива GDPR. В России за это отвечает ФЗ-152 «О персональных данных». Мы расскажем о требованиях, которые предъявляют эти положения к работе с ПД на рынках РФ и Европы.

Европейский подход

GDPR в Европе работает с 25 мая 2018 года. Под его действие попадают все компании (интернациональные в том числе), которые хранят или обрабатывают персональные данные граждан Евросоюза.

Что считать ПД по GDPR?

Персональными считаются данные, по которым можно установить личность владельца – пользователя сервиса (хотя бы косвенно): ФИО, домашний адрес, IP-адрес, логин на каком-либо сайте и другие идентификаторы. Сюда же относится информация, касающаяся социальной или культурной принадлежности.

Еще в GDPR выделена особая категория конфиденциальных данных. Она включает религиозные убеждения гражданина, его биометрические показатели, а также медицинские сведения.

Требования к операторам данных

• Получать согласие на обработку данных. Обрабатывать персональные данные без согласия их владельца запрещено. При этом нельзя считать согласием молчание или бездействие пользователя. Также оператор должен сообщить, с какой целью используется собираемая информация.
• Защищать персональные данные. Компания-обработчик обязана защитить ПД от кражи, повреждения или подмены. Поэтому сведения должны шифроваться, а их распространение – контролироваться.
• Назначать сотрудников по защите данных. Они управляют бизнес-процессами, касающимися работы с ПД, и следят за соблюдением требований GDPR. Это особенно важно, если организация проводит масштабные исследования или обрабатывает большие объемы конфиденциальных сведений (например, медицинских записей).
• Обеспечивать право на забвение. Обработчик обязан удалить ПД пользователя по запросу, если это требование не идет вразрез с интересами сообщества или другими правами жителей ЕС.
• Уведомлять представителей регулятора об утечках данных. Об уязвимости нужно сообщить в течение трех дней с момента обнаружения «бреши».

Нарушения требований директивы GDPR караются крупными штрафами. Они могут достигать 20 миллионов евро или 4% годового оборота организации. Первые иски в суд появились в день начала работы регламента – пользователи обвинили в нарушениях ИТ-гигантов Facebook и Google. Но пока к компаниям санкции не применялись. Регулятор хотел дать организациям адаптироваться к новым реалиям.

Как обрабатывать ПД в России

В РФ работу компаний с ПД клиентов и пользователей регулирует ФЗ-152 «О защите персональных данных». Он обязателен для исполнения всеми компаниями, зарегистрированными в России, а также филиалами иностранных организаций.

Что считать ПД по ФЗ-152?

Определение ПД в ФЗ-152 похоже на то, что дает GDPR: персональными данными считается любая информация, с помощью которой можно установить личность человека (номер телефона, номер банковской карты и так далее).

Требования к операторам данных

• Получать согласие на обработку ПД. Дополнительно оператор ПД должен сообщить пользователю, какая информация о нем собирается и в каких целях применяется. Например, на нашем сайте все это прописано в политиках конфиденциальности.
• Без согласия человека можно обрабатывать только ПД из открытых источников.Однако здесь нужно соблюдать осторожность, так как были прецеденты (по решению верховного и арбитражного судов нашей страны), когда данные в открытом доступе по разным причинам оказывались запрещены для обработки.
• Собирать только ту информацию, которая необходима для работы предоставляемого сервиса. Собирать и хранить данные «на всякий случай» запрещено. По этой причине владелец интернет-магазина не имеет права просить у пользователей сканы паспортов.
• Удалять или обезличивать более ненужные ПД. Оператор должен уничтожить неактуальные данные или обновить и уточнить данные, в которых есть ошибки.

Штрафы за нарушение требований закона разные для физических и юридических лиц и варьируются от 1000 до 75 тыс. рублей. Например, физическое лицо получит штраф в 3–5 тыс. рублей за обработку ПД без согласия владельца. Юрлицу то же нарушение обойдется в 30–75 тыс. рублей.

Чем поможет облачный провайдер

В обоих законах – российском ФЗ-152 и европейском GDPR – сказано, что оператор может делегировать обработку ПД третьей стороне (если владелец персональных данных на это согласен).

Часто в роли третьей стороны выступает IaaS-провайдер. Он предоставляет инфраструктуру с полным набором технических и административных систем защиты персональных данных. Например, эту услугу предоставляем мы в «ИТ-ГРАД». Она называется «Облако ФЗ-152».

У нас защищенный хостинг, в основе которого оборудование таких компаний, как Dell, NetApp, Juniper, Cisco и др. Система снабжена программно-аппаратным комплексом шифрования. Такая инфраструктура снижает юридические риски компаний.

Сервис «Облако ФЗ-152» подходит как для отечественных, так и для иностранных организаций. Все они получают возможность работать с клиентами из РФ в полном соответствии с законом и обеспечивать высокий уровень защищенности персональных данных пользователей.

Оригинал статьи в блоге ИТ-ГРАД.

На прошедшей в августе конференции VMworld 2018 компания VMware сделала множество интересных анонсов (больше, чем в прошлом году, кстати). Одним из таких анонсов стало обновление решения VMware vRealize Network Insight 3.9 (vRNI), которое предназначено для обеспечения сетевой безопасности виртуальной инфраструктуры. Напомним, что о прошлой версии vRNI 3.8 мы писали вот тут.

Давайте посмотрим на новые возможности VMware vRNI 3.9:

1. Доступность продукта как SaaS.

Теперь пользователи облачных инфраструктур могут использовать решение vRNI для защиты своих сред. Сама инфраструктура облачного vRNI размещена в лондонском датацентре, а для безопасного доступа к сервисам, защищенным vRNI, можно использовать многофакторную аутентификацию. С точки зрения затрат, можно заключить контракт на использование облачного vRNI сроком на 1 или 3 года.

2. Инеграция в инфраструктуру Virtual Cloud Network.

vRNI теперь опирается на инфраструктуру Virtual Cloud Network, построенную на основе технологии NSX. Она позволит объединить гетерогенные онпремизные и облачные сети, а также пользователей и устройства, соединяющиеся с ними по всему миру. Задача vRNI здесь - обеспечить безопасность и аналитику сетевого обмена в рамках NSX Data Center, в том числе на уровне модулей NSX-T.

3. Улучшенные средства анализа сетевого трафика в облаке и на площадке заказчика.

Теперь в решении появились кастомные дашборды для каждого пользователя, поддержка сетевого экрана Cisco ASA, а также улучшились средства поддержки фаервола Checkpoint. Также сводные данные о метриках каждой из площадок (онпремизных или облачных) агрегируются в рамках единых представлений.

Доступность vRNI 3.9 для загрузки ожидается к ноябрю этого года.

На завершившейся сейчас в Лас-Вегасе конференции VMworld 2018 компания VMware представила немало интересных анонсов, о которых мы расскажем в ближайшем будущем. Среди них одними из самых обсуждаемых стало объявление о выпуске vSphere 6.7 Update 1 и новое издание vSphere Platinum.

Давайте посмотрим, что такое vSphere Platinum, из чего состоит это решение, и для кого оно предназначено. Прежде всего, vSphere Platinum - это комбинация из двух продуктов: платформы VMware vSphere Enterprise Plus и решения VMware AppDefense.

Но это не просто сочетание двух продуктов, это еще и специальный плагин к vCenter для vSphere Client, который и реализует их сопряжение (называется он vCenter Server plugin for vSphere Platinum). Это дает доступ администраторам к функциональности AppDefense через стандартные средства управления платформой vSphere.

Суть технологии AppDefense заключается в том, что она изучает нормальное поведение операционной системы и приложений при обычных условиях, пользователь определяет это состояние как "нормальное", а в случае выявления отклонений от этого состояния, оповещает об этом администратора и автоматически предпринимает некоторые шаги по защите окружения.

Главный интерфейс AppDefense предназначен для администраторов безопасности, а вот плагин к vCenter для AppDefense больше нацелен на администраторов vSphere. Он позволяет сопоставить данные AppDefense, такие как процессы и угрозы, виртуальным машинам и сетям, в которых они актуальны.

Вот, например, представление для администратора безопасности в консоли AppDefense:

Здесь можно увидеть много всего интересного, но нет самого главного - к каким виртуальным машинам относится эта информация о приложениях.

Поэтому зайдем в дэшборд плагина vSphere Client к AppDefense, где можно увидеть эту информацию:

Здесь видны инфраструктурные объекты - хосты и виртуальные машины (вместо IP-адресов и портов в AppDefense). Поэтому администратор может разобраться с угрозами, относящимися к приложениями с помощью управления конфигурациями хостов и виртуальных машин.

Более того, администратор vSphere может зайти на вкладку Monitor, где в категории AppDefense получить список всех процессов внутри гостевой ОС и их состояний:

Таким образом, администратор vSphere может взаимодействовать с администратором безопасности, который работает с консолью AppDefense, в целях выявления и устранения угроз безопасности в виртуальной инфраструктуре. Кстати, сам плагин к vCenter доступен только если вы покупаете решение vSphere Platinum пакетом.

В итоге, vSphere Platinum содержит в себе следующие компоненты и технологии обеспечения безопасности:

• Решение VMware AppDefense.
• Защита данных по стандарту FIPS 140-2 за счет шифрования ВМ, а также шифрования миграций (Encrypted vMotion).
• Технология Secure Boot for ESXi – не позволяет посторонним компонентам работать на уровне гипервизора.
• Secure Boot for Virtual Machines – предотвращает неавторизованное изменение виртуальных машин.
• Поддержка модуля TPM 2.0 для ESXi – проверяет целостность гипервизора при загрузке и предоставляет функции удаленной аттестации хостов.
• Устройства Virtual TPM 2.0 – дает функции безопасности для гостевых ОС, при этом все операционные возможности (например, vMotion или disaster recovery) остаются доступными.
• Поддержка Microsoft Virtualization Based Security для ОС Windows 10 и Windows 2016, включая возможности Credential Guard на платформе vSphere.
• Audit Quality Logging – предоставляет администраторам высокую степень детализации при анализе происходящих в vSphere операций.

Кстати, интересная фишка - при покупке лицензий vSphere Platinum для 5 процессоров или более, пользователи будут получать $10 000 на счет для использования публичного облака VMware Cloud on AWS. Это позволит опробовать технологии организации гибридного облака (подробнее об этой программе - тут).

О доступности для загрузки vSphere Platinum будет объявлено несколько позднее.

Многие пользователи кластера отказоустойчивости хранилищ VMware vSAN замечали, что в настройках служб кластера есть такая опция "Erase disks before use", которая доступна при шифровании хранилища (vSAN Encryption).

Эта настройка позволяет очистить диск перед использованием шифрования на нем, чтобы соблюсти требования к безопасности хранения и обслуживания данных, например, NIST 800-88 Revision 1, определение "Clear":

Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).

В приложении A приведенного выше документа есть такая таблица (приведены только 2 строки из нее):

Чтобы соблюсти эти гайдлайны, кластер vSAN может вычищать предыдущие данные добавляемого диска перед первым использованием. Но при этом блоки заполняются не нулями или однотипными значениями - ведь это может вызвать сбой механизмов дедупликации и компрессии, поэтому в блоки записываются просто случайные данные.

Ставя галку "Erase disks before use" надо понимать, что процесс заполнения блоков случайными значениями занимает значительное время, которое зависит от типа используемого хранилища и инфраструктуры хранения в целом.

Также важно помнить, что включение vSAN Encryption влечет за собой шифрование только новых создаваемых дисковых объектов и не применяется к существующим на хранилище блокам (то есть их потенциально можно считать с диска, расшифровка их не потребуется). Таким образом, использование vSAN Encryption с настройкой "Erase disks before use" имеет смысл только при добавлении устройств, где ранее существовали данные.

Поэтому:

• Включайте опцию "Erase disks before use", когда:
  • Включаете vSAN Encryption для существующуего vSAN кластера, в котором требуется вычистить свободные блоки.
  • Добавляете хост, который имел ранее данные на локальных дисках, в кластер vSAN.
  • Выполняете операцию rekey для инициации процедуры deep rekey (запрос нового KEK и новых уникальных DEKs для каждого устройства vSAN).
• Не обязательно включать "Erase disks before use", когда:
  • Включаете vSAN Encryption для полностью нового кластера vSAN, в котором ранее не было данных на добавляемых дисках.
  • Добавляете в кластер vSAN хост, у которого на локальных дисках не было чувствительных данных.
  • Выполняете операцию rekey для инициации процедуры shallow rekey (только запрос нового KEK).

На днях компания VMware выпустила обновление своего пакета для гостевых систем VMware Tools 10.3.0. Напомним, что о прошлом обновлении VMware Tools 10.2.5 мы писали тут.

Главное нововведение тулзов версии 10.3 - это закрытая уязвимость HGFS Out-Of-Bounds Read, которая могла привести к повышению привилегий злоумышленника в гостевой ОС виртуальной машины (для этого должны быть включены сервисы File sharing на ВМ с Windows на борту). Более подробную информацию об этой уязвимости можно найти в статье CVE-2018-6969.

Также в VMware Tools 10.3.0 появились следующие новые возможности:

• Интеграция с механизмом VMware AppDefense (о том, что это такое, мы писали вот тут).
• Обновления в драйвере OpenGL - были сделаны оптимизации Vertex buffer object (VBO) и Display list drawing.
• В драйвере VMXNET3 для Windows появилась поддержка Receive data ring.
• Для Shared Folders в Linux появился клиент на базе FUSE (необходима версия ядра 3.10 и выше).
• Компилятор для VMware Tools 10.3.0 for Windows был обновлен до Microsoft Visual Studio 2015.
• Множество исправлений ошибок.

Скачать VMware Tools 10.3 можно по этой ссылке.

Компания VMware на сайте проекта VMware Labs опубликовала полезную утилиту SDDC Certificate Tool. Она позволяет автоматизировать процесс замены сертификатов SSL в различных продуктах VMware, который всегда был очень геморройным. Теперь, будем надеяться, за счет этой утилиты он превратится в нечто более дружественное.

Для замены сертификатов поддерживаются следующие решения:

Наверное вы заметили, что в списке нет ESXi - это обусловлено тем, что для замены сертификатов требуется эвакуация всех виртуальных машин с хоста, что может занять очень значительное время, поэтому поддержки пока такой нет (но, может быть, появится).

Надо отметить, что это довольно большой набор продуктов для первой версии, охватывающий практически всю линейку решений для управления, мониторинга и автоматизации датацентров (именно поэтому в названии утилиты есть SDDC - Software-Defined Data Center).

Помимо настройки сертификатов, утилита позволяет перенастроить трасты между компонентами по окончании процесса настройки. Утилита работает из командной строки (вам понадобится Linux-сервер с Java 1.8+) и автоматизирует многие шаги, которые ранее нужно было выполнять вручную с помощью Certificate Generation Utility (CertGen). На входе она принимает JSON-конфигурацию, в которой описывается требуемое множество поддерживаемых продуктов VMware.

Приятно, что в составе утилиты уже имеются множество пре-чеков перед заменой сертификатов - определение срока действия, валидация цепочки и прочее, а также сверка введенных параметров (например, число узлов vSAN) с фактическими. Для использования SDDC Certificate Tool подойдет PhotonOS, которую можно скачать отсюда.

Небольшая демка по использованию утилиты (кстати, напомним, что она на данный момент в статусе технологического превью):

Скачать в виде rpm-пакета можно по этой ссылке. Детальные инструкции по использованию утилиты находятся тут.

Как вы знаете, компания VMware часто выпускает обновления для платформы VMware ESXi, которые закрывают проблемы безопасности и содержат исправления ошибок. Эти обновления можно загрузить вручную через портал My VMware или автоматически накатить через VMware Update Manager (VUM). Обновление содержит коллекцию VIB-пакетов, которые последовательно накатываются в среде ESXi. Эта коллекция VIB объединяется в бюллетень (bulletin), чтобы соблюсти порядок установки и зависимости, которые между ними заложены. Одно обновление содержит один или несколько бюллетеней.

Есть два типа бюллетеней для обновления VMware vSphere: патчи (patches) и роллапы (rollups). При любом выпуске обновления для ESXi есть как минимум бюллетень, который содержит основные системные пакеты - esx-base, vsan, and vsanhealth. Также в обновление могут быть включены и другие бюллетени, если есть необходимость в их обновлении.

Если обновление небольшое, то оно называется патчем (patch) и содержит небольшой набор пакетов, который закрывает дырки безопасности и некоторые баги. Время от времени VMware выпускает большой набор обновлений, который содержит не только исправления ошибок, но и некоторые новые возможности - оно называется rollup.

Раньше администраторам довольно трудно было убедиться, что у них накатаны все необходимые патчи в промежутке времени между большими мажорными релизами VMware vSphere. Теперь же, начиная с июня этого года, вместе с каждым патчем выходит еще и rollup update, который содержит в себе все обновления пакетов, которые произошли с момента последнего релиза VMware vSphere.

Вот так это выглядит в VMware Update Manager:

Все эти обновления описаны в соответствующей статье базы знаний VMware. Например, взгляните на VMware KB 55917 - там описаны все бюллетени обновления ESXi670-201806001 с соответствующими ссылками на их KB, а также указан rollup bulletin, который содержит все обновления VIB-пакетов с момента последнего релиза, в данном случае VMware ESXi 6.7:

Теперь можно просто накатывать этот роллап и не волноваться, что в вашей инфраструктуре что-то не обновлено.

В конце мая компания VMware выпустила обновленную версию продукта VMware Unified Access Gateway (UAG) версии 3.3. Это решение представляет собой шлюз для доступа к инфраструктуре VMware Workspace ONE и VMware Horizon. Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам решения Workspace ONE, виртуальным десктопам и приложениям.

Давайте посмотрим, что нового появилось в этом продукте:

1. Поддержка механизма Device Certificate Authentication для обратного прокси-сервера.

Аутентификация на базе сертификатов вместе с поддержкой Web Reverse Proxy используется для защиты внутренних сайтов, таких как SharePoint, Outlook OWA и т.п. при доступе с внешних устройств.   

2. Логирование действий администратора.

Теперь все действия пользователя admin записываются в файл audit.log:

Также записываются и операции по скачиванию данного лога.

3. Отсутствие зависимости от Network Protocol Profile.

Раньше на платформе vSphere профиль Network Protocol Profile (NPP) или IP Pool должны были иметь соответствующие сети на стороне UAG с такими же настройками IP, шлюза и т.п. Теперь нет необходимости настраивать все это на стороне vSphere, а вместо этого при развертывании UAG нужно указать маску IPv4, префикс IPv6 и шлюз по умолчанию.

4. Поддержка TLS Port 443 Sharing.

Теперь такие сервисы, как Horizon Blast, туннель для конкретного приложения, Content Gateway и Web reverse proxy идут по одному порту 443. Это минимизирует требования к добавлению новых правил в сетевой экран в DMZ.

Этот механизм также можно отключить через настройку tlsPortSharingEnabled.

5. Одновременная работа с IPv4 и IPv6 (Dual Mode).

С помощью Dual Mode пользователи инфраструктуры VMware Horizon могут использовать смешанный парк устройств, работающих, как с IPv4, так и с IPv6 в рамках одного соединения (например, карточка IPv6 на мобильном устройстве и NIC с IPv4 на Connection Server).

6. Редактирование настроек сетевого адаптера через веб-интерфейс.

В веб-интерфейсе виртуального модуля UAG администратор теперь может задавать IP-настройки сетевого адаптера:

7. Новая операционная система виртуального модуля.

Теперь Virtual Appliance решения UAG работает на базе собственной операционной системы VMware - Photon OS. которая позиционируется как наиболее защищенная система для виртуальной инфраструктуры.

8. Настройки масштаба инфраструктуры.

Теперь при развертывании UAG можно задать одну из двух настроек масштаба:

• Standard – рекомендуется при развертывании Horizon до 2000 одновременных подключений, либо для инфраструктуры Workspace ONE UEM (мобильные устройства) до 10 000 подключений.
• Large – это нужно для инфраструктуры Workspace ONE UEM, когда нужно поддерживать более 10 000 одновременных подключений. Это позволяет механизмам Content Gateway, Per App Tunnel & Proxy и Reverse Proxy использовать один виртуальный модуль UAG.

Скачать VMware Unified Access Gateway 3.3 можно по этой ссылке.

Компания VMware на днях выпустила обновление своего средства для обеспечения сетевой безопасности витуальной инфраструктуры VMware vRealize Network Insight 3.8 (vRNI). Напомним, что о новых функциях версии vRNI 3.6 мы писали вот тут.

Давайте посмотрим, что нового появилось в vRNI 3.8:

1. Функции Outlier Detection.

Эта возможность позволяет обнаруживать аномалии в паттернах трафика каждой виртуальной машины, когда она является частью заданной группы, но при этом ведет себя, с точки зрения сетевой активности, не так, как остальные.

Такая активность анализируется аналитическим движком и визуализуется на графике. Также по подозрительным машинам показывается дополнительная информация, такая как объем трафика, число сессий и IP-адрес. Это позволяет выявить не только подозрительные активности, но и определить неправильно настроенные ВМ (например, балансировщики).

2. Улучшения работы с сервисом Amazon AWS.

Здесь было сделано множество мелких улучшений:

Очень важная фича для пользователей облачных инфраструктур AWS - поддержка зон доступности (Availability Zones) при просмотре окружения, поиске машин и их фильтрации. Также несколько поменялся интерфейс, облачные инстансы теперь обозначаются как AWS EC2, а AWS Manager переименован в AWS Account.

3. Интеграция с VMware Log Insight.

Про это средство для централизованного сбора и анализа логов мы много пишем в последнее время. Теперь в vRNI 3.8 можно посылать webhook-нотификации сразу же, как случается какое-то событие. Log Insight через этот механизм может посылать в сторону vRNI алерты, например, об изменении Security Groups в решении VMware NSX (эти изменения фиксируются в логах, которые обрабатывает Log Insight).

Также в VMware vRealize Network Insight 3.8 появилось несколько небольших нововведений, полный список которых указан в Release Notes. Скачать vRNI 3.8 можно по этой ссылке.

Мы иногда пишем о том, что большие обновления как хост-серверов VMware ESXi, так и управляющих компонентов VMware vCenter / vCenter Server Appliance всегда лучше ставить заново, а не делать апгрейд с предыдущих версий (если у вас, конечно, есть такая возможность). Да, вы не сохраните логи и исторические данные, но это позволит вам избежать различных проблем, связанных с устаревшими компонентами, которые останутся при обновлении и могут вступить в конфликт с новыми функциями при определенных обстоятельствах.

Такой вот пример приводит и Mike Foley в статье про механизм безопасной загрузки хостов vSphere Secure Boot. Когда он обновил свою инфраструктуру на VMware vSphere 6.7 с версии 6.5, он решил проверить функции Secure Boot и возможности модуля TPM 2.0.

Но когда он включил эти возможности в UEFI BIOS, он получил "розовый экран смерти" (PSOD) сервера ESXi:

Причина оказалась проста - для некоторых legacy-драйверов при обновлении не были обновлены их сигнатуры для VIB-пакетов, поэтому механизм Secure Boot не может эти сигнатуры проверить и выводит хост в PSOD при загрузке.

Чтобы найти эти драйверы, он запустил скрипт secureBoot.py, который показывает модули, препятствующие безопасной загрузке:

/usr/lib/vmware/secureboot/bin/secureBoot.py -c

Вывод оказался примерно таким:

[root@esxi-117] /usr/lib/vmware/secureboot/bin/secureBoot.py -c Secure boot CANNOT be enabled: 

Failed to verify signatures of the following vib(s): [

net-tg3 

dell-configuration-vib 

net-i40e 

net-igb 

net-ixgbe 

vmware-esx-perccli-1.05.08 

ima-qla4xxx 

misc-cnic-register 

net-bnx2 

net-bnx2x 

net-cnic 

net-qlcnic 

net-qlge 

scsi-bnx2fc 

scsi-bnx2i 

scsi-qla4xxx 

scsi-megaraid-sas 

lsu-lsi-mptsas-plugin].

All tardisks validated. All acceptance levels validated

Посмотрев на каждый драйвер по отдельности, он понял, что все это старые Linux-драйверы, которые были заменены в новых версиях VMware vSphere своими Native-аналогами. Например, для драйвера net-tg3 есть аналогичный нативный драйвер ntg3, а для net-bnx2i есть bnxnet.

Поэтому далее Майк просто удалил все VIB-пакеты со старыми драйверами следующей командой:

esxcli software vib remove -n scsi-megaraid-sas

esxcli software vib remove -n net-tg3

esxcli software vib remove -n net-i40e

esxcli software vib remove -n net-igb

esxcli software vib remove -n net-ixgbe

esxcli software vib remove -n net-qlcnic

esxcli software vib remove -n scsi-bnx2i

esxcli software vib remove -n scsi-bnx2fc

esxcli software vib remove -n net-bnx2x

esxcli software vib remove -n scsi-qla4xxx

esxcli software vib remove -n net-cnic

esxcli software vib remove -n net-bnx2

esxcli software vib remove -n net-qlge

esxcli software vib remove -n misc-cnic-register

esxcli software vib remove -n lsu-lsi-mptsas-plugin

esxcli software vib remove -n ima-qla4xxx

esxcli software vib remove -n vmware-esx-perccli-1.05.08

esxcli software vib remove -n dell-configuration-vib

В итоге его хост смог безопасно загрузиться через Secure Boot. Также Майк далее в статье рассматривает решение еще одной специфической проблемы, которая встречается довольно редко.

Ну а мы еще раз напомним - если есть возможность поставить новую мажорную версию ESXi с нуля - лучше скачайте ISO-образ и сделайте это, вместо того, чтобы "быстро и безопасно" обновиться на новую версию.

Поскольку российское законодательство накладывает ряд требований на процесс обработки и хранения персональных данных (ПДн), компании уже сегодня размещают собственные ПДн в облаке провайдера. Как не нарушить закон и соответствовать требованиям регулятора, какая ответственность возлагается на оператора ПДн и провайдера, что должен знать клиент, выбирая поставщика услуг хостинга персональных данных по ФЗ-152? На эти и другие вопросы ответим в сегодняшней статье...

Как все уже знают, недавно компания VMware выпустила обновленную версию платформы виртуализации VMware vSphere 6.7. Напомним наши статьи о нововведениях этого решения:

• Новая версия платформы виртуализации VMware vSphere 6.7 доступна для скачивания
• Сравнение максимумов конфигурации VMware vSphere 6.5 и 6.7
• Новые возможности VMware vCenter 6.7 - развертывание vCSA стало опцией по умолчанию
• Как отреагировали вендоры решений резервного копирования виртуальных машин на релиз VMware vSphere 6.7
• Новые возможности VMware vSAN 6.7 в составе vSphere 6.7
• Обновленный VMware Update Manager в vSphere Client 6.7
• Рекомендации по обновлению на VMware vSphere 6.7

Ну а сегодня мы расскажем еще об одной возможности vSphere в плане безопасности - поддержке технологии Virtualization Based Security (VBS) операционных систем Microsoft. Механизм VBS позволяет превратить сервер или рабочую станцию на базе ОС Windows Server 2016 или Windows 10 в защищенные системы, исполняющиеся в рамках гипервизора Windows, при этом некоторые компоненты выносятся за пределы гостевой системы. Например, за рамки ОС выносится система управления хэшированными парами логин/пароль (креденшены), называющаяся Credential Guard.

Как мы видим на картинке, гипервизор обеспечивает виртуализацию гостевой системы на сервере или ноутбуке, а также канал обмена между внешними компонентами (Credential Guard, Device Guard) и ОС. Такая архитектура обеспечивает большие трудности при доступе злоумышленников к областям памяти, где хранятся хэши паролей различных пользователей - ведь эта область вынесена за пределы операционной системы.

Также аппаратное обеспечение компьютера должно иметь в своем составе модуль TPM 2.0 (Trusted Platform Module), который обеспечивает механику безопасной загрузки (Secure Boot). Ведь если не использовать механизм безопасной загрузки, то атаку можно провести на сам гипервизор, подменив его компоненты, а дальше уже иметь доступ к основной виртуальной машине и остальным компонентам гипервизора, в том числе хранилищу паролей. Таким образом, для полной защиты нужно использовать связку VBS+TPM 2.0 (вторая версия TPM поставляется уже со всем современным оборудованием).

Чтобы такая схема работала, нужно обеспечить выполнение следующих требований:

• UEFI firmware (не BIOS).
• Опция безопасной загрузки Secure Boot с поддержкой TPM.
• Поддержка технологии Hardware virtualization (опция процессоров Intel VT/AMD-V) и функций IOMMU.

И самое главное - ОС Windows должна быть установлена со всеми этими включенными опциями, иначе потом настраивать VBS будет проблематично.

В случае с гипервизором ESXi для незащищенной виртуальной машины Windows все выглядит вот таким образом:

Чтобы защитить машину с помощью VBS, потребуется использовать вложенную (nested) виртуализацию - ведь гипервизор Windows Hypervisor надо запустить на платформе VMware ESXi. Для этого в настройках виртуальной машины надо выставить опцию Enable для пункта Virtualization Based Security:

Это позволит открыть все необходимые опции процессора для гостевой ОС виртуальной машины, в которой также будет работать гипервизор.

Выглядеть это будет следующим образом:

Чтобы эта схема работала, нужно выполнить 2 условия:

• Виртуальная машина должна иметь виртуальное железо Virtual Hardware версии 14, которое появилось в vSphere 6.7.
• Гостевую ОС виртуальной машины надо развертывать на базе UEFI и с уже включенной опцией Secure Boot (обратите внимание на эту опцию на панели Boot Options в разделе VM Options (см. скриншот настроек выше).

Ну и последняя деталь - это модуль TPM. Для физических систем этот модуль делается с расчетом на одну систему, имеет небольшой объем памяти защищенного хранилища (измеряется в килобайтах) и работает весьма медленно, так как это serial device.

Поэтому VMware сделала виртуальное устройство - vTPM 2.0, которое в качестве хранилища использует обычный файл .nvram. Физический TPM не рассчитан на то, чтобы поддерживать сотни виртуальных машин на одном сервере (просто не хватит объема хранилища и быстродействия), а виртуальный vTPM отлично справляется с этой задачей. К тому же, виртуальную машину с виртуальным vTPM можно переносить между серверами с помощью vMotion и делать ее резервные копии.

Но, само собой, файл nvram надо хорошо зашифровать, поэтому для виртуальной машины нужно включить VM Encryption. Это обеспечит работоспособность машины в защищенной среде совместно с опцией VBS. При этом диски ВМ шифрованными не будут, что позволит получить доступ к данным на уровне VMDK дисков в случае утери ключей.

Самое интересное, что vTPM 2.0 не требуется как-то отдельно устанавливать и настраивать - он автоматически обнаруживается средствами Windows со стандартными драйверами:

Утилита Device Guard and Credential Guard hardware readiness tool от компании Microsoft определяет этот vTPM, как совместимый, поэтому можете использовать его для виртуальных машин, к которым предъявляются повышенные требования к безопасности.

Теперь, когда ситуация с трактованием персональных данных прояснилась (смотрите статью «Тонкости законодательства – что относится к персональным данным с точки зрения российского регулятора»), самое время обсудить требования, предъявляемые законом к обработке ПДн.

О чем говорит закон

Здесь сразу стоит обратить внимание на принципы обработки ПДн, введенные в статьях 5 и 6 закона «О персональных данных». Рассмотрим наиболее значимые пункты:

• Обработка ПДн должна проводиться на законной и справедливой основе, то есть для каждого случая обработки персональных данных должно быть законное основание, или нормы, прямо предусмотренные законодательством, или согласие субъекта ПДн.
• Закон требует ограничивать обработку ПДн конкретными, заранее определенными и законными целями, при этом нельзя обрабатывать данные в целях, которые не были заявлены при сборе.

• Состав и объем обрабатываемых персональных данных должен соответствовать цели их обработки. Отклонение от указанных требований является нарушением.

• Следующий принцип обработки – точность, достаточность и актуальностьобрабатываемых данных. Если данные являются неточными, неактуальными, незаконно полученными или не соответствуют цели обработки, закон требует от оператора ПДн либо уточнить эти данные, либо уничтожить. Во многих случаях это оказывает влияние на решение, принимаемое в отношении субъектов ПДн, и затрагивает их законные права.
• Последний принцип, на котором надо остановиться – закон разрешает хранить ПДн только до того момента, когда будет достигнута цель обработки или минует надобность для достижения этой цели. После этого данные должны быть уничтожены или обезличены.

Условия обработки персональных данных

Следующий важный момент касается условий обработки персональных данных. Для лучшего понимания мы подготовили перечень, который позволит определить, насколько законной является обработка ПДн.

• Наличие согласия субъекта ПДн. Помните, что наличие согласия субъекта персональных данных – это всегда правильно и хорошо. Причем оно должно быть сознательным, информированным и конкретным. В некоторых случаях одного согласия может быть недостаточно, в дополнение требуется определить цель, которая будет достигаться, и действия, которые будут выполняться с ПДн.
• Обработка ПДн допускается, если это предусмотрено в международном договоре или законе. Это особенно важно понимать, поскольку в России существует масса законов, прямо предписывающих организацию обработки ПДн, начиная от Трудового кодекса, закона «О связи», заканчивая законами «О кредитных историях», «О банках и банковской деятельности».
• Наличие договора, в котором субъект ПДн выступает выгодоприобретателем/поручителем, или наличие инициативы субъекта заключить такой договор. Предположим, человек ищет работу и отправляет свое резюме или анкету в компанию. В этом случае получать согласие от соискателя на вакантную должность не требуется, поскольку, предоставив резюме, человек выражает стремление заключить трудовой договор и тем самым дает согласие на обработку ПДн. Однако в последнее время Роскомнадзор поясняет что, если сбор резюме производится через веб-сайт, это требует получения от субъекта согласия на обработку ПДн.
• Без согласия могут обрабатываться ПДн, полученные из общедоступных источников, которые подлежат опубликованию или обязательному раскрытию. Несмотря на кажущуюся простоту и очевидность рассматриваемого вопроса, подходить к этому пункту стоит с особой осторожностью. Дело в том, что было несколько громких дел, когда решение верховного и арбитражного судов сводилось к тому, что без согласия доказываемого субъекта ПДн данные, размещенные на общедоступном источнике для неограниченного доступа пользователей, было запрещено обрабатывать. С этим можно соглашаться или не соглашаться, но решение суда для ряда конкретных случаев вступило в законную силу.

Согласие субъекта – тонкости и особенности

Но и здесь не обходится без нюансов. Как показывает практика, наиболее частым способом выражения согласия являются конгруэнтные действия, когда, к примеру, посетитель предоставляет паспорт на ресепшен и с документом производят какие-либо действия: ксерокопируют, сканируют, выписывают данные, при этом человек молчит, подтверждая тем самым согласие на обработку ПДн. Помните, что такой способ выражения согласия не предусмотрен законом.

Какие требования необходимо выполнить, если сбор ПДн осуществляется через веб-сайт?

В этом случае регулятор хочет видеть дисклеймер, который говорит о согласии субъекта с пользовательским соглашением, определяющим порядок работы с персональными данными и политикой оператора, сведения которого реализуются для защиты этих ПДн.

В некоторых случаях закон предусматривает не просто согласие в любой доказанной форме, а согласие в письменном виде. Закон «О персональных данных» описывает пять таких ситуаций:

• Включение персональных данных в общедоступные источники.
• Обработка специальных категорий персональных данных.
• Обработка биометрических персональных данных.
• Трансграничная передача персональных данных на территорию иностранных государств, не обеспечивающих адекватную защиту прав субъектов.
• Принятие решений, порождающих юридические последствия в отношении субъекта или иным образом затрагивающих его права и законные интересы, на основании исключительно автоматизированной обработки его персональных данных.

При этом два случая в законе «О персональных данных» явным образом не прописаны. К ним относятся:

• Распространение персональных данных членов (участников) общественного объединения или религиозной организации.
• Передача ПДн третьим лицам, если условием лицензии на осуществление деятельности оператора является запрет на такую передачу.

Остались вопросы?

Переходите по ссылке на запись вебинара Облако в соответствии с законом «О персональных данных» и следите за новыми материалами первого блога о корпоративном IaaS. В следующей статье мы рассмотрим зоны ответственности заказчика и облачного провайдера, поговорим об особенностях аутсорсинга обработки ПДн, а также расскажем, на что следует обратить внимание при выборе провайдера, предлагающего услуги по «ФЗ-152».

Оригинал статьи в блоге ИТ-ГРАД.

Продолжаем информировать вас о выпусках обновлений и заплаток уязвимостей Meltdown и Spectre для виртуальной инфраструктуры VMware vSphere. Напомним наши прошлые посты:

• Как отслеживать производительность хостов VMware ESXi после патчей Meltdown и Spectre с помощью VMware vSphere Operations Manager
• Вышел VMware vCenter Server Appliance 6.5 Update 1f - исправлена уязвимость Meltdown и Spectre (частично)
• Производительность хост-серверов VMware ESXi и других платформ после наката патчей для Meltdown и Spectre
• Для VMware vSphere, Workstation и Fusion пофикшена уязвимость Spectre
• Скрипт для проверки виртуальной инфраструктуры VMware vSphere на подверженность уязвимости Spectre

На днях наш читатель Стас прислал новость о том, что VMware выпустила обновления, закрывающие уязвимость Spectre, на этот раз для ключевых компонентов виртуальной инфраструктуры - серверов vCenter и ESXi. Таким образом, согласно VMware Security Advisory VMSA-2018-0004.3, теперь от уязвимости Spectre защищены все основные продукты VMware трех последних поколений:

Начнем с обновлений для vCenter. Тут были выпущены следующие апдейты:

• VMware vCenter Server 5.5 Update 3h (Release notes, скачать)
• VMware vCenter Server 6.0 Update 3e (Release notes, скачать)
• VMware vCenter Server 6.5 Update 1g (Release notes, скачать)

Для серверов VMware ESXi были выпущены следующие патчи:

• ESXi550-201803001 (ESXi550-201803401-BG и ESXi550-201803402-BG)

• ESXi600-201803001 (ESXi600-201803401-BG и ESXi600-201803402-BG)

• ESXi650-201803001 (ESXi650-201803401-BG и ESXi650-201803402-BG)

Чтобы скачать эти обновления для ESXi, нужно пойти VMware Patch Portal и поискать там обновления для соответствующей версии ESXi.

Кроме наката патчей гипервизора VMware ESXi, вам также придется обновить микрокод серверов. Более подробная информация об этом приведена в KB 52085.

Помните, что порядок наката обновлений безопасности таков:

1. Накатываем обновления vCenter.

2. Обновляем ПО гипервизора на серверах VMware ESXi - накатываем апдейты, заканчивающиеся на 01-BG (позволяет гостевым ОС использовать новый механизм speculative-execution control), одновременно с этим обновляем и микрокод серверов (апдейты, заканчивающиеся на 02-BG), которое применяется в процессе загрузки ESXi. Оба патча накатываются в рамках одного профиля.

Прошлой весной компания VMware выпустила релиз своего основного документа по обеспечению безопасности виртуальной среды Security Configuration Guide для vSphere 6.5. Напомним, что ранее подобный документ назывался Hardening Guide и был основным руководством для сотрудников отделов ИТ-безопасности по настройке гипервизора ESXi и виртуальных машин.

На днях VMware выпустила финальную версию документа vSphere 6.5 Update 1 Security Configuration Guide, в котором приведены основные конфигурации для обеспечения безопасности уже Update 1, то есть последнего на данный момент мажорного обновления платформы vSphere.

В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:

• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
• Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.

Надо отметить, что от релиза к релизу Security Configuration Guide становится все меньше, так как VMware продвигает идеологию, что платформа становится защищеннее из коробки (Secure By Default). На данный момент осталось всего 68 конфигураций для всей виртуальной среды.

При работе с гайдлайнами инженеры VMware каждый раз проверяют актуальность тех или иных настроек, изменяют их или удаляют. Кстати, удаляют они их вот по каким причинам:

• Код vSphere постоянно ревьювится, и некоторые введенные улучшения делают так, что какой-то из описанных гайдлайнов больше не является вектором угрозы. Пример - настройка "disable-intervm-vmci". Сам по себе этот механизм был удален из состава vSphere, а значит ушла и рекомендация по этой настройке.
• Также некоторые гайдлайны ранее были невыполнимыми (например, verify-kernel-modules) - многие пытались писать свои скрипты для верификации каждого модуля VMkernel при загрузке, пока VMware не сделала цифровые подписи VIB-модулей, за счет которых распространяются компоненты vSphere, и механизм Secure Boot.
• Некоторые гайдлайны были написаны для фичей, которые некорректно понимались с точки зрения безопасности. Например, считалось, что настройка VM.disable-hgfs актуальна для vSphere, но оказалось, что она применяется только для Workstation и Fusion и никакой угрозы не несет.

Также поменялись некоторые дефолтные значения для настроек безопасности, которые ранее по умолчанию вообще не имели значений. Например, настройки ниже имеют указанные явно значения TRUE, чтобы не вводить пользователя в заблуждение - типа, а как это работает по умолчанию?

Давайте посмотрим на статистику того, что изменилось в гайдлайнах, и как они теперь выглядят:

Скачать VMware vSphere 6.5 Update 1 Security Configuration Guide можно по этой ссылке.

Последние версии платформ виртуализации основных вендоров - VMware, Microsoft и OpenStack - фактически сравнялись по своим характеристиками, и сегодня клиент чаще всего выбирает решение не по максимальным характеристикам, а по цене, удобству управления инфраструктурой и различным рискам, в том числе, связанным с поставкой софта в Россию. Мы сделали принципиальный шаг вперёд, чтобы дать клиентам более широкий выбор вендоров при старте нового проекта или просчете рисков продления существующих лицензий. В июле 2017 года был представлен 5nine Manager Datacenter...

Некоторые из вас знают, что VMware и другие производители в последнее время борются с уязвимостями Meltdown и Spectre в процессорах Intel, выпуская и отзывая патчи для различных компонентов ИТ-инфраструктуры. Мы писали об этом не так давно в следующих заметках:

• Вышел VMware vCenter Server Appliance 6.5 Update 1f - исправлена уязвимость Meltdown и Spectre (частично)
• Производительность хост-серверов VMware ESXi и других платформ после наката патчей для Meltdown и Spectre
• Для VMware vSphere, Workstation и Fusion пофикшена уязвимость Spectre
• Скрипт для проверки виртуальной инфраструктуры VMware vSphere на подверженность уязвимости Spectre

Как вы знаете, из за патчей для данных уязвимостей на серверах ESXi иногда существенно проседает производительность (также подробно об этом написано тут), что необходимо отслеживать для того, чтобы не оказаться в ситуации неожиданного недостатка ресурсов в кластере после его апгрейда.

Напомним основные статьи VMware KB, касающиеся исправлений данных уязвимостей:

• https://kb.vmware.com/s/article/52245 
• https://kb.vmware.com/s/article/52337

Еще в декабре 2017 некоторые из уязвимостей были пофикшены, но с тех пор у многих пользователей VMware vSphere появились проблемы с производительностью.

Один из сотрудников VMware опубликовал полезную заметку о том, как с помощью решения vRealize Operations Manager можно отслеживать производительность хостов ESXi в кластерах VMware HA/DRS и на основе этого принимать решения о патчинге тех или иных производственных сред и кластеров.

1. Трекинг версий BIOS и хостов ESXi для каждого сервера с использованием дэшборда Host Configuration.

Этот инструмент нужен, чтобы не забыть пропатчить хост-серверы ESXi:

2. Просмотр информации об использовании виртуальными машинами системных ресурсов.

3. Также надо смотреть на изменения CPU и Memory Usage на уровне кластера с помощью дэшборда Capacity Overview.

4. С помощью дэшборда Heavy Hitters можно выяснить, какие из ВМ сейчас действительно сильно грузят оборудование.

5. Также если у вас есть 2 кластера, которые выполняют одну функцию в плане рабочих нагрузок - вы можете переместить нагрузки с помощью функции Workload Balance.

6. Возможность перераспределения емкости кластера можно узнать с помощью дэшборда Capacity Reclaimable.

7. Использование кастомных дэшбордов для Meltdown и Spectre.

Это возможно, если у вас издание vRealize Operations Advanced или более высокое, так как оно позволяет создавать кастомные дэшборды. Сотрудники VMware, Iwan Rahabok, Mark Scott и Luciano Gomes, разработали специальные дэшборды, которые сфокусированы на конфигурации, производительности, емкости и утилизации виртуальной инфраструктуры. Скачать все три дэшборда вместе с инструкциями можно по этой ссылке.

Эти следующие три дэшборда:

• Performance Monitoring
• Planning Guest OS Patching
• Tracking vSphere Patching

7.1 Дэшборд Performance Monitoring.

Этот дэшборд позволяет отслеживать производительность CPU и памяти на всех уровнях - ВМ, хост, кластер. Соответственно, сравнивая исторические периоды, вы сможете сделать вывод о падении производительности.

7.2 Дэшборд Planning Guest OS Patching.

Этот дэшборд нужен для того, чтобы спланировать патчинг гостевых ОС. Сначала находятся все простаивающее ВМ, апдейт которых не сильно повлияет на функционирование виртуальной инфраструктуры, а в последнюю очередь идет обновление так называемых "heavy hitters" - рабочих лошадок вашего предприятия, апдейт которых должен проводиться с особой осторожностью.

7.3 Дэшборд Tracking vSphere Patching.

Этот дэшборд помогает планировать апгрейд различных версий VMware ESXi, а также версий виртуального аппаратного обеспечения (Virtual Hardware) виртуальных машин. Он решает 2 практические задачи:

• Отслеживание номеров билдов VMware ESXi и прогресса патчинга серверов.
• Отслеживание Virtual Hardware различных ВМ.

Совокупность всех этих инструментов позволит вам не только грамотно спланировать весь процесс патчинга гостевых ОС и хост-серверов, но и измерить влияние на производительность результата апгрейда хостов ESXi и прочих компонентов виртуальной инфраструктуры.

Как вы знаете, некоторое время назад были обнаружены серьезные уязвимости в процессорах компании Intel, условно называемые Meltdown и Spectre. Вскоре после их обнаружения многие производители выпустили обновления микрокода оборудования, многие из которых оказались неготовыми к эксплуатации в производственной среде (происходили неожиданные перезагрузки, падала производительность и появлялись другие эффекты).

VMware тогда тоже выпустила обновления для VMware ESXi и vCenter, закрывающие потенциальные угрозы, но через несколько дней была вынуждена отозвать их обратно ввиду тех же самых эффектов.

Теперь, наконец, вышло обновление VMware vCenter Server Appliance 6.5 Update 1f, содержащее исправления для серверов управления на базе виртуального модуля с Photon OS на борту, исправляющее следующие дыры в безопасности:

• Bounds-check bypass (уязвимость Spectre-1, CVE-2017-5753)
• Rogue data cache load issues (уязвимость Meltdown, CVE-2017-5754)

Надо отметить, что уязвимость Spectre-2 (Branch target injection - CVE-2017-5715) по-прежнему не исправлена в данном релизе.

Патч VMware vCenter 6.5 Update 1f можно загрузить с VMware Patch Portal (VMware-VCSA-all-6.5.0-7801515.iso):

В процессе апдейта будут обновлены следующие пакеты:

• linux 4.4.110-2
• libgcrypt 1.7.6-3
• c-ares 1.12.0-2
• ncurses 6.0-8
• libtasn1 4.12-1
• wget 1.18-3
• procmail 3.22-4
• rsync 3.1.2-4
• apr 1.5.2-7

Также помимо VMware vCSA патч доступен и для решения vSphere Integrated Containers 1.3.1. На данный момент матрица выхода апдейтов фикса Meltdown и Spectre выглядит весьма удручающе (более подробно - вот тут):

Пропатчить VMware vCSA можно также через GUI из дефолтного репозитория обновлений продукта.

Ну и мы все еще ждем обновления для хостов VMware ESXi, которые до сих пор в статусе "Patch Pending".

Почти все из вас в курсе, что недавно в процессорах Intel были найдены уязвимости Meltdown и Spectre. Недавно мы писали о том, то компания VMware выпустила патчи для хост-серверов VMware ESXi, а также для управляющего сервера vCenter. Вильям Лам даже написал скрипт PowerCLI для проверки накаченных обновлений на хосты и виртуальные машины.

Но...18 января VMware, получив некую "важную информацию" от Intel, отозвала выпущенные патчи и опубликовала специальную KB 117649, в которой описала сложившуюся ситуацию, не особенно ее проясняя. Пока мы ждем патчей от VMware и Intel, можно взглянуть на некоторые результаты тестов производительности (раз и два), где показано, как исправления микрокода серверов от описанных уязвимостей негативно влияют на производительность:

Говорят, что падение производительности для тяжелых нагрузок (особенно по вводу-выводу) может составить от 5% до 30%, что как бы очень много.

В связи с этими событиями (последствия от которых еще проявят себя в ближайшие недели), компания Login VSI сделала специальную бесплатную лицензию на свое одноименное средство тестирования (мы писали об одной из версий тут). Запросить бесплатную лицензию на инструмент Login VSI можно по этой ссылке. Она, кстати, абсолютно ничем не ограничена - ни числом хостов, ни виртуальных машин в вашей виртуальной инфраструктуре, а для тестирования доступны все рабочие нагрузки.

Единственное ее ограничение - бесплатная версия прекратит работать 31 марта этого года. С помощью Login VSI вы можете протестировать производительность таких платформ, как Citrix XenApp, XenDesktop, Microsoft RDS и, конечно же, VMware Horizon View. 

В целом, влияние обновлений безопасности на производительность особенно чувствительно именно для VDI-инфраструктур, где коэффициент консолидации виртуальных машин на хостах существенно выше, чем в серверной среде.

Запросить бесплатную лицензию на Login VSI можно здесь.

На днях мы писали о том, что компания VMware выпустила обновления VMware vCenter и ESXi, закрывающие потенциальную угрозу безопасности Spectre (она же Hypervisor-Assisted Guest Mitigation - CVE-2017-5715), которая недавно была обнаружена в процессорах Intel. Для закрытия уязвимости нужно обновить не только серверы ESXi и vCenter, но и микрокод (BIOS/Firmware) серверов (более подробная информация также приведена в KB 52085).

На днях наш читатель Сергей прислал ссылку на скрипт от Вильяма Лама, который позволяет провести проверку компонентов виртуальной инфраструктуры VMware vSphere на данную уязвимость. Этот PowerCLI-скрипт содержит две функции:

• Verify-ESXiMicrocodePatchAndVM
• Verify-ESXiMicrocodePatch

Первая функция позволяет проверить хосты ESXi и виртуальные машины и сгенерировать отчет в разрезе виртуальных машин. Если в колонке Affected стоит значение False - значит обновления и микрокода сервера, и хоста ESXi были применены, а сами ВМ и хост-сервер не подвержены уязвимости Spectre.

Вторая функция проверяет только, что на хостах ESXi накачено обновление как микрокода, так и самого гипервизора ESXi, который видит обновленные CPU features.

Функция Verify-ESXiMicrocodePatchAndVM может быть запущена тремя способами:

• Без параметров - проверяется все окружение VMware vSphere и все виртуальные машины в нем.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты и ВМ.
• С параметром - VMName - проверяется только конкретная ВМ и ее хост, соответственно.

У функции Verify-ESXiMicrocodePatch также есть три способа вызова:

• Без параметров - проверяются все хост-сервера в инфраструктуре vCenter.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты.
• С параметром - VMHostName - проверяется конкретный хост-сервер ESXi.

Скачать этот PowerCLI-сценарий можно по этой ссылке: VerifyESXiMicrocodePatch.ps1.

Кстати говоря, этот скрипт был добавлен в полезный скрипт vCheck, который перед Новым годом обновился до версии 6.25, скачать его можно вот тут - https://github.com/alanrenouf/vCheck-vSphere.

Те из вас, кто следят за ИТ-новостями, наверняка слышали о последних уязвимостях, обнаруженных в процессорах Intel. Одной из таких уязвимостей стала Spectre - она потенциально позволяет локальным приложениям (локальному атакующему, при запуске специальной программы) получить доступ к содержимому виртуальной памяти текущего приложения или других программ.

На днях компания VMware опубликовала обновления для своей платформы VMware vSphere, которые устраняют потенциальные проблемы со Spectre (сама уязвимость описана вот тут).

Исправления для серверов VMware vCenter можно скачать по этим ссылкам:

• VMware vCenter Server 5.5 Update 3g - Release Notes - Загрузить
• VMware vCenter Server 6.0 U3d - Release Notes - Загрузить
• VMware vCenter Server 6.5 U1e - Release Notes - Загрузить

Вы можете скачать как установочный образ:

так и патч к vCenter с VMware Patch Portal (ищите обновление от 9 января):

Для серверов VMware ESXi надо пойти на VMware Patch Portal и загрузить оттуда обновление ESXi650-201801401-BG / ESXi650-201801402-BG. (номер билда 7526125). Подробная информация об обновлении приведена в KB 2151099.

Также данное исправление доступно и для настольных платформ виртуализации VMware:

• VMware Workstation 14.1.1 Pro for Linux - Загрузить
• VMware Workstation 14.1.1 Pro for Windows - Загрузить
• VMware Fusion 10.1.1 (для Intel-based Macs) - Загрузить
• VMware Fusion 8.5.10 (для Mac OS X) - Загрузить

Спасибо нашему читателю Стасу за новость об этих исправлениях.

«Код безопасности» анонсировал выход продукта vGate 4.0. Решение для защиты виртуальных инфраструктур будет востребовано компаниями, применяющими виртуальные платформы VMware vSphere или Microsoft Hyper-V последних версий. Продукт позволяет настроить инфраструктуру согласно различным требованиям с помощью наборов политик, разграничить права доступа администраторов, а также обеспечить защиту от несанкционированного доступа к виртуализованным ресурсам.

Известный своими скриптами блоггер Luc Dekens (LucD) опубликовал интересный сценарий PowerCLI для виртуальной инфраструктуры VMware vSphere, который позволяет вычистить права доступа на объекты, для которых уже существуют права на уровне родительских объектов.

Например, у вас есть такая картина:

Соответственно, нам нужно почистить пермиссии в папке Test1131 для пользователя Local\test, чтобы разрешения остались только на уровне родительского объекта Test1 (там, как мы видим, установлена опция применения разрешений вниз к дочерним объектам).

Собственно, сам скрипт:

<#
.SYNOPSIS
  Find and remove redundant permissions on vSphere objects 
.DESCRIPTION
  The function will recursively scan the permissions on the
  inventory objects passed via the Entity parameter.
  Redundant permissions will be removed.
.NOTES
  Author:  Luc Dekens
.PARAMETER Entity
  One or more vSphere inventory objects from where the scan
  shall start
.EXAMPLE
  PS> Optimize-Permission -Entity Folder1 -WhatIf
.EXAMPLE
  PS> Optimize-Permission -Entity Folder?
.EXAMPLE
  PS> Get-Folder -Name Folder* | Optimize-Permission
#>
 
  [cmdletbinding(SupportsShouldProcess=$true)]
  param(
    [parameter(ValueFromPipeline)]
    [PSObject[]]$Entity
  )
 
  Begin{
    function Optimize-iVIPermission{
      [cmdletbinding(SupportsShouldProcess=$true)]
      param(
        [parameter(ValueFromPipeline)]
        [VMware.Vim.ManagedObjectReference]$Entity,
        [VMware.Vim.Permission[]]$Permission = $null
      )
 
      Process{
        $entityObj = Get-View -Id $Entity
        $removePermission = @()
        $newParentPermission = @()
        if($Permission){
          foreach($currentPermission in $entityObj.Permission){
            foreach($parentPermission in $Permission){
              if($parentPermission.Principal -eq $currentPermission.Principal -and
                 $parentPermission.RoleId -eq $currentPermission.RoleId){
                $removePermission += $currentPermission
                break
              }
              else{
                $newParentPermission += $currentPermission
              }
            }
          }
        }
        else{
          $newParentPermission += $entityObj.Permission
        }
        if($removePermission){
          if($pscmdlet.ShouldProcess("$($entityObj.Name)", "Cleaning up permissions")){
            $removePermission | %{
              $authMgr.RemoveEntityPermission($Entity,$_.Principal,$_.Group)
            }
          }
        }
        $Permission += $newParentPermission
       
        if($entityObj.ChildEntity){
            $entityObj.ChildEntity | Optimize-iVIPermission -Permission $Permission
        }
      }
    }
  }
 
  Process{
    foreach($entry in $Entity){
       if($entry -is [System.String]){
        $entry = Get-Inventory -Name $entry
       }
       Optimize-iVIPermission -Entity $entry.ExtensionData.MoRef
    }
  }
}

Скрипт работает так, что пробегается по дереву объектов, обнаруживает избыточные разрешения и удаляет их. У скрипта есть удобный параметр WhatIf, который выводит операции по очистке разрешений, которые как бы применяются к дочерним объектам, но на самом деле не применяет их:

Optimize-VIPermission -Entity Test1 -WhatIf

Результатом будет список объектов, где разрешения будут очищены, в данном случае, если посмотреть на пример выше, это будет папка Test1131:

Можно запустить скрипт и на 2 папки сразу:

Optimize-VIPermission -Entity Test1,Test2 -WhatIf

Результат будет таким (в папке Test22 также есть дублирующиеся разрешения):

Также можно использовать и конструкции с масками, например:

Get-Folder -Name Test? | Optimize-VIPermission -WhatIf

Теперь неплохо было бы, если бы кто-то написал GUI к этой штуке, а также добавил туда функции поиска и удаления произвольных разрешений в выбранных объектах.

Довольно давно мы уже рассказывали о механизме применения политик для хранилищ при развертывании виртуальных машин - VMware vSphere Storage Policy Based Management (SPBM). А недавно Кормак Хоган опубликовал интересную заметку, касающуюся возможности выбора политик SPBM конкретным пользователем во время развертывания новой виртуальной машины.

Прежде всего, в vSphere нет механизма назначения прав доступа пользователей на конкретную политику SPBM - все пользователи видят все политики. Но сам механизм разграничения прав существует - его можно реализовать на уровне прав доступа к хранилищам.

Например, пользователю ben мы даем доступ Read-only к хранилищу VVols1, то есть создавать виртуальные машины он на нем не может:

А на хранилище VVols2 делаем его администратором:

В итоге, при развертываниии виртуальной машины пользователь ben видит оба хранилища - VVols1 и VVols2 и все доступные политики хранилищ (комбобокс VM storage policy):

Однако, обратите внимание, что при выборе хранилища VVols1 в разделе Compatibility написано о том, что пользователь не имеет достаточных привилегий, чтобы создать машину на этом датасторе.

You do not hold the privilege to allocate space on the selected datastore

Между тем, кнопка Next активна. Но если нажать ее, мастер все равно дальше не пустит:

Вверху мы увидим:

Specify a valid location

Ну а если выбрать VVols2, то все проверки пройдут успешно, и пользователь сможет там создать виртуальную машину:

С момента выхода последнего мажорного релиза платформы виртуализации VMware vSphere 6.5 мы много писали о шифровании виртуальных машин (и, кроме того, затрагивали тему производительности этого процесса), а также техниках шифрования кластеров vSAN (и некоторых особенностях этого). Сегодня мы поговорим о самом важном компоненте инфраструктуры шифрования vSphere - Key Management Service (KMS).

Прежде всего, KMS - это сервисы шифрования не только для виртуальных машин, но и любых других объектов ИТ-инфраструктуры. Поэтому KMS уже может быть в вашей организации, при этом он может не быть прикрученным к VMware vSphere. Вы можете использовать любой KMS-сервер, но VMware сертифицировала лишь следующие системы из списка (см. вот этот документ VMware):

Если же у вас другой KMS-провайдер, не расстраивайтесь - он, скорее всего, будет работать, если поддерживает протокол управления ключами KMIP 1.1.

Начать надо с вопросов доступности KMS-сервера. Как вы понимаете, это самый важный сервер в вашей инфраструктуре, важнее DNS или контроллера домена. Если у вас недоступен DNS, все тоже не работает, как и в случае с KMS, но если оказались недоступными данные хранилища KMS - это катастрофа для организации. И нет абсолютно никакого пути восстановить их. Совершенно никакого. Обо всем этом рассказывает видео ниже:

Таким образом, KMS становится бизнес-критичной точкой не только инфраструктуры, но и бизнеса в целом. И вопросы бэкапа и его доступности - это вопросы номер 1. Давайте посмотрим на несколько базовых понятий KMS:

• KMIP (Key Management Interoperability Protocol) - это стандарт, по которому клиент KMIP может общаться с серверами KMS. Каждый год он проходит серьезную проверку на конференции RSA.
• DEK (Data Encryption Key). Это ключ, который хост ESXi генерирует, когда требуется зашифровать виртуальную машину. Этот ключ используется также и для расшифровывания данных ВМ, он записан в VMX/VM Advanced settings в зашифрованном виде.
• KEK (Key Encryption Key). Это ключ, которым зашифрован DEK. KEK key ID также находится в VMX/VM Advanced settings.
• Key Manager Cluster/Alias - это коллекция адресов FQDN/IP всех реплицируемых между собой серверов KMS. Она также хранится вместе с зашифрованной машиной в VMX/VM Advanced settings, чтобы после ее включения можно было обратиться к нужному кластеру KMS, получить KEK для cервера vCenter, который разлочит ВМ.
• VM и vSAN encryption - это, на самом деле, с точки зрения реализации механизма шифрования одно и то же. То есть, для обоих типов шифрования используются одни и те же библиотеки, конфигурации и интерфейсы.

Когда мы говорим о кластере KMS - это всего лишь KMS-серверы, реплицирующие между собой хранилища ключей. Они не обеспечивают доступность друг друга, как, например, это делает VMware HA. Например, есть серверы KMS-A, KMS-B и KMS-C, в хранилищах которых при добавлении ключа новой ВМ он появляется мгновенно.

Если KMS-A недоступен как сервер, то сервер vCenter запрашивает ключи у хоста KMS-B. Если же KMS-A недоступен как сервис (то есть сервер работает, а служба KMS не отвечает), то vCenter ждет 60 секунд восстановления работоспособности сервиса и только потом переключается на KMS-B. Это поведение изменить нельзя.

Лучшие практики по использованию KMS таковы:

• По возможности нужно делегировать обязанности по поддержке инфраструктуры KMS отдельной команде (Security Team) или человеку.
• Не класть KMS-серверы в виртуальной машине в тот же кластер (например, vSAN), который также зашифрован. Иначе коробочка закроется (выключится кластер), а ключ от нее останется внутри нее же. То есть, необходимо держать хотя бы один из KMS-серверов за пределами такого домена отказа.
• Предыдущий пункт относится и к серверам vCenter и PSC. Чтобы они могли расшифровать другие сервера, они должны быть доступны в случае сбоя.

Теперь надо сказать о катастрофоустойчивости серверов KMS. Типичный кластер в рамках одной площадки выглядит так:

Но если на этой площадке будет авария, которая затронет все 3 сервера - бизнесу может настать конец. Поэтому в идеале надо использовать конфигурацию с двумя площадками:

Понятное дело, что у малого и среднего бизнеса резервных площадок, как правило, нет. В этом случае помочь может публичное облако Amazon AWS или Microsoft Azure. Чтобы поддерживать там одну резервную машину, много денег не нужно.

Ну и если вы используете конфигурацию с несколькими площадками, то обязательно нужно учитывать в конфигурации порядок обращения к серверам KMS в рамках площадки. Если на первой площадке находятся сервера KMS-A, KMS-B и KMS-C, а на второй - KMS-D, KMS-E и KMS-F, то в первом случае порядок должен быть A,B,C,D,E,F, а во втором - D,E,F,A,B,C.

Если на второй площадке вы будете использовать конфигурацию аналогичную первой, сервер vCenter может ходить по серверам другой площадки, которая может быть недоступна, а только обойдя все ее серверы, начнет использовать локальные KMS.

Рано или поздно каждый администратор приходит к тому, что ему необходимо каким-то образом сохранить, а потом и извлечь учётные данные. Причём это должно быть быстро, эффективно, удобно и самое главное безопасно. Ни один из известных мне способов не отвечал всем этим требованиям одновременно. Я стал искать и нашел свой способ, которым и хочу поделиться с вами. Это PowerCLI! Удивлены? Порой самое простое решение лежит на поверхности.